1. Field
The described embodiments relate to computing devices. More specifically, the described embodiments relate to accessing time stamps during transactions in a processor in a computing device.
2. Related Art
In some existing processors, one or more instructions in program code may be grouped into what is called a “critical section.” In these processors, before executing a critical section, an executing entity (e.g., processor core, thread, etc.) acquires a lock (e.g., by writing a 1 to a lock variable). The entity then executes the program code in the critical section, releasing the lock (e.g., by writing a 0 to the lock variable) when finished executing the critical section. The lock, once acquired, prevents the concurrent execution of the critical section or another critical section that is protected by the same lock by another entity (e.g., processor core, thread, etc.). In other words, in these processors, instructions in two or more critical sections that are protected by the same lock are mutually exclusive and thus should not be executed concurrently. This mutual exclusion property of critical sections can be referred to as “single lock atomicity” or “SLA.”
Some existing processors support “transactional memory.” Transactional memory is typically implemented in a processor by enabling entities (e.g., processor cores, threads, etc.) on the processor to execute sections of program code in “transactions,” during which program code is executed normally, but transactional operations are prevented from permanently effecting the architectural state of the processor. For example, memory accesses (reads and writes) are allowed during transactions, but transactional writes may be held locally and prevented from being committed to one or more levels of a memory hierarchy in the processor during the transaction. In these processors, during transactions, memory accesses from other entities are monitored to determine if a memory access from another entity interferes with a transactional memory access (e.g., if another entity writes data to a memory location read during the transaction, etc.) and transactional operations are monitored to ensure that an error condition has not occurred. If an interfering memory access or an error condition is detected during the transaction, the transaction is aborted, a pre-transactional state of the entity is restored, and the entity may retry the transaction (or some error-handling routine may be performed). Otherwise, if the entity completes the transaction by executing the section of program code without encountering an interfering memory access or an error condition, the entity commits the transaction, which includes committing the held transactional operations (writes, state changes, etc.) to the architectural state of the processor.
In some transactional memory processors, to enable more efficient execution, the above-described critical sections are executed in transactions. In these processors, upon encountering a critical section, the processor does not acquire the lock (called “lock elision”), but, instead, executes the critical section in a transaction, perhaps concurrently with one or more other transactions that are being performed for critical sections that are protected by the same lock. The replacement of lock-based critical sections with transactions generally provides the appearance to entities on the processor that the critical sections have not been executed concurrently. However, in certain cases, this appearance can be lost and hence violations of SLA can become apparent. For example, some processors provide instructions such as read time stamp counter and processor (or “RDTSCP”) that enable entities to acquire a current time in the processor (a “time stamp”). These time stamps are often used to determine order between events. Because time-stamp acquisition instructions can appear in critical sections, when two or more critical sections are executed concurrently in transactions, one or more of the transactions could acquire time stamps that indicate/prove that the critical sections were not executed mutually exclusively.
One possible technique for handling a transactional time stamp acquisition is to simply abort the transaction upon detecting an instruction that acquires a time stamp. However, because time stamp acquisition occurs fairly frequently in program code, accepting this simple solution can lead to inefficient operation (i.e., a larger percentage of transactions than need to be may be aborted).